The present invention relates to mobile communications systems, and more particularly to techniques for allocating Temporary Mobile Subscriber Identities (TMSIs) in circuit switched and/or packet switched mobile communications systems.
Mobile communications systems are well known. In so-called “cellular” or “mobile” networks, a large geographical area is divided up into so-called cells. Each cell is served by a corresponding base station, which uses radiocommunication techniques to link mobile units located within the cell to a land-based part of the cellular communication system. The land-based part of the cellular communication system (called the Public Land Mobile Network—“PLMN”) is capable not only of linking communications between mobile units located in the same or different cells, but also of connecting a mobile user to other communications networks, such as a Public Switched Telephone Network (PSTN) and/or a computer-oriented data network. In this way, a mobile user may be capable of establishing a call to (or receiving a call from) a non-mobile telephone (a so-called “Plain Old Telephone”, or “POT”) or to processing equipment connected to a computer network. When a user of a mobile unit moves from one cell to another, responsibility for maintaining any ongoing call that he may be participating in shifts from the original cell to the new “target” cell, in an operation referred to as “handoff” or “handover”.
The cellular radiocommunication industry has made phenomenal strides in commercial operations in many countries around the world. Growth in major metropolitan areas has far exceeded expectations and is rapidly outstripping system capacity. If this trend continues, the effects of this industry's growth will soon reach even the smallest markets. Innovative solutions are required to meet these increasing capacity needs as well as to maintain high quality service and avoid rising prices.
While the basic principles outlined above are generally applicable to all such mobile communications systems, each system implementation is made in conformance with a selected one of a number of possible standards. In order to facilitate an understanding of the invention, the various problems and inventive solutions described herein are presented in the context of the well-known Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS) and 3rd Generation Partnership Project (3GPP) standards, each of which is well-known and need not be described herein in detail. However, it should be understood that the principles to be discussed are not restricted to only those systems, but instead are readily transportable in alternative embodiments to mobile communications systems implemented in accordance with other standards that utilize the equivalent of a TMSI.
In mobile networks, the Visitor Location Registers (VLRs) and Serving GPRS Support Nodes (SGSNs) support identity confidentiality by allocating a TMSI to each visiting mobile subscriber (MS). The TMSI is a temporary identity alias that is used instead of the permanently-assigned International Mobile Subscriber Identity (IMSI). This alias must be agreed on before-hand between the mobile station and the network during protected signaling procedures. A mobile station (MS) can be allocated two TMSIs: one for services provided through the Mobile Switching Center (MSC), and another (called P-TMSI) for services provided through the SGSN. A mobile is considered “visiting” when it attaches to a specific VLR and/or SGSN of the PLMN.
To facilitate the discussion, all references to “TMSI” (whether abbreviated or spelled out as “Temporary Mobile Subscriber Identity”) in this document should be construed to mean “TMSI and/or P-TMSI”, unless otherwise stated.
Since the TMSI has only local significance (i.e., within a VLR area controlled by a VLR, or within an SGSN area controlled by an SGSN), the coding of the TMSI can be chosen by agreement between operator and manufacturer in order to meet local needs.
The TMSI consists of a predefined number of bits, such as four octets (i.e., thirty-two bits). It can be coded using a full hexadecimal representation. In areas where both MSC-based services and SGSN-based services are provided, some discriminating coding is done to distinguish between the allocation of TMSIs for MSC-based services and the allocation of TMSIs for SGSN-based services.
FIG. 1 is a diagram of a conventional TMSI 100 that is used in exemplary existing systems. In this example, the discriminating coding is located in a Circuit Switched (CS)/Packet Switched (PS) field 101 that occupies the two most significant bits of the TMSI 100. In the CS/PS field 101, the values 00, 01 and 10 are used to indicate that the TMSI 100 is associated with VLR-based services (i.e., CS-based services); the remaining value “11” is used to indicate that the TMSI 100 is associated with SGSN-based services (i.e., PS-based services). Of course, in other systems, the CS/PS field could be encoded in other ways. Furthermore, the CS/PS field need not be located in the most significant portion of the TMSI, nor does it have to be two-bits wide.
The basic problem of 2nd generation (2G) and future 3rd Generation (3G) networks is the expected huge increase in the amount of traffic to be handled, and in the number of subscribers in both GSM and Universal Mobile Telecommunication System (UMTS) markets. The traditional solution to the MSC capacity problem has been to develop more powerful processors for the MSCs and, when that is no longer possible, to add MSCs to the network. The addition of the MSCs to the network has, however, led to new problems, namely the need for continuous network re-configurations and the increase in location updating and inter-MSC handover traffic. The same applies also to SGSN nodes, for both 2G and 3G networks.
To tackle both problems (capacity and network configuration) an approach based on the “MSC in pool” (for 2G networks) and “SGSN in pool” (for 3G networks) concepts has been proposed. To better appreciate the various aspects of the pool concept (to be described below with reference to FIG. 2), it is helpful to first examine existing cellular network architectures.
In current cellular network architectures there is a hierarchical structure between core network nodes (MSC/VLR and SGSN) and radio access network nodes (Base Station Controller/Radio Network Controller—“BSC/RNC”). In today's systems, a number of base stations are grouped together and associated with a BSC/RNC. BSCs/RNCs are, in turn, grouped together and associated with, an MSC/VLR and an SGSN. In other words, from the core network (CN) perspective, the current network philosophy is to geographically divide the region between the available core network resources, that is, an MSC/VLR in the CS domain and an SGSN in the PS Domain.
By contrast, and with reference to the block diagram of FIG. 2, the characteristics of the pool concept are that the hierarchical network structure is arranged such that:                Each MSC and/or SGSN server within the pool 201 serves the same service area (i.e., the so-called “pool service area.”        Each of the RNCs 203 within the pool service area is connected to each of the servers within the pool 201, that is, an RNC/BSC can now contact several MSC's/SGSN's.        The RNCs 203 within the pool service area have a traffic distribution functionality, which distributes the mobile traffic between the servers within the pool 201 and achieves in that way a load distribution between the servers.        
A greater detailed description of the “in pool” concept can be found, for example, in “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Intra Domain Connection of RAN Nodes to Multiple CN Nodes; (Release 5)”, 3GPP TS 23.xyz, v0.0.0 (2001-01), which is hereby incorporated herein by reference in its entirety.
As anticipated by the last bulleted paragraph, the problem when introducing server pools in the core network is determining on what basis an RCN/BSC should decide which MSC/SGSN to route messages to.
The solution currently suggested is to distribute the messages based on the value of the TMSI. The TMSI is the 32-bit temporary identity assigned to a subscriber by the MSC/VLR or SGSN, but as applied in this environment it is unique within an entire pool service area instead of just a single server.
Indeed, in accordance with this strategy, each server (MSC/VLR and SGSN) of the pool 201 handles only a subset of all possible TMSIs, and each RNC 203 always distributes/assigns the subscriber to the same and unique server of the pool 201, based on the TMSI that the subscriber has.
The assumption behind this distribution concept is that each subscriber (or group of subscribers) produces on average the same amount of load on the system. Consequently, the load ought to be at least approximately evenly distributed among the various servers within the pool 201.
A problem arises, however, when one attempts to apply existing TMSI allocation strategies to the new “in pool”-based environment. To better understand the nature of this problem, it is helpful to first examine how TMSIs are structured and allocated in existing systems.
Presently, in systems not employing the “in pool” concept, the TMSI is allocated on a per-VLR basis (i.e., the TMSI is unique on VLR level).
The structure of a prior art TMSI 300 is shown in FIG. 3. Here it can be seen that, in addition to the CS/PS field 101, the TMSI 300 is made up of two fields: a TMSI identification field 301 which points to the subscriber records in the VLR (each server is able to handle up to 1 million subscribers), and a TMSI generation field 303. In this example, the TMSI identification field 301 is 20 bits wide (which is capable of representing a unique value for each of the 1 million potential subscribers), and the TMSI generation field 303 is 12 bits wide.
The 12-bit TMSI generation field 303 is wide enough to allow 3,072 TMSI generation values for CS services and 1,024 TMSI generation values for PS services.
Double allocation is a situation in which two different MSs hold the same TMSI identification with the same generation value at the same time. As can be imagined, this would be a problem since it would be impossible, under these circumstances, for the system to distinguish one MS from the other. The TMSI generation field is used to avoid double allocation of TMSIs. For example, if a subscriber A with a given TMSI identification value does not show up anymore (i.e., the subscriber does not do a “Cancel Location” operation) then this TMSI identification value should (and will) be released after a certain period of time so that it can be used for another user B. Otherwise, a TMSI identification field value would be blocked forever and the number of free TMSI identification values would decrease. To distinguish the new subscriber B from subscriber A (who should not be allowed to use his old TMSI anymore), the TMSI identification field value is additionally associated with a “TMSI generation” value which tells the system the current generation of a certain TMSI identification value. Only the subscriber using a TMSI identification value associated with the correct generation field value is allowed to access the network.
The TMSI generation field value is stepped each time an already released TMSI identification field value is allocated to a different/new subscriber, due to any of the following reasons:                a subscriber moves to a different location area (LA) of the same VLR; or        a Cancel Location occurs when the subscriber moves to a new LA in a new VLR service area.        
After some time, the TMSI generation field value will likely be stepped several times, but not equally for all TMSI identification values. For example, it can happen that TMSI identification field value 5075 is in generation 8, while the TMSI identification field value 2034 is still in generation 2.
If one of the following happens:                MSC/VLR restart with reload;        HLR reset; or        Deregistration (Purge from HLR),then the TMSI generation field value is again stepped, but this time by a value higher than 1, such as 50 or even 500! This is necessary because in these instances, the VLR loses all information about the TMSI generation values, and therefore doesn't know in which generation the various TMSI identification values were. In order to make sure that all subscribers/terminals are released from the network, which would force them all to re-register (necessary when a restart happens), each of the TMSI generation field values has to be set high enough to cause it to exceed the value that it had just before the restart-causing event. A step size of 50–500 (which is used in today's systems) is assumed to be large enough to ensure this condition. The relatively large range of the generation field values (3,072 possibilities for CS services, 1,024 possibilities for PS services) allows the use of such large steps, although in most cases they are probably much larger than actually necessary. Only in rare instances will it happen that there are users who had previously been assigned an even higher TMSI generation field value. Extra signaling is required to then release these few users, but the small number of them means that the higher signaling load is small, and therefore no problem. Thus, with the current TMSI allocation policy of TMSI generation stepping, the probability of double TMSI allocation is very low.        
Turning now to systems that employ the “in pool” concept, such systems require a restructuring of the TMSI. In particular, the entire TMSI range has been divided among different servers, so that only a certain range of the TMSI values is valid for any given server.
As of this writing, 3GPP plans to standardize the TMSI structure 400 depicted in FIG. 4. A Domain field 401 is 3-bits wide, and its value identifies whether the TMSI is associated with CS services, PS services, or other uses.
A TMSI generation field 403 is present, but is allocated only 5 bits out of the entire TMSI 400.
A Server pointer field 405 is allocated 7 bits of the TMSI 400.
A TMSI identification field 407 in the TMSI is allocated 17 bits, which enables the addressing of up to 132K subscribers.
In use, each subscriber will be assigned the correct server based on the value of the server pointer field 405. Each server will be able to handle 132K subscribers.
This new TMSI structure 400 presents problems with respect to TMSI allocation. In particular,                The TMSI generation field has been reduced to only 5 bits, which means that there are only 32 possible values. As a result of this reduction, the probability of a double TMSI allocation occurring becomes much higher if conventional TMSI allocation strategies are employed.        Moreover, a step by 50 to 500 is not even possible anymore, so a new algorithm is needed to replace the former procedure of incrementing in the range of 50–500. Furthermore, the conventional technique for picking a step size is not ideal, since under the conventional TMSI allocation strategy, the appropriate step size depends very much on the future user behavior and mobility pattern. In some cases a step size of 8 could be a good value, while in other cases the step size should be 15 or higher.        
Selection of a suitable step size also depends on the type of server, MSC or SGSN. There is also uncertainty whether a value of, for example, 8 will be the best one to use all the time.
There is therefore a need for a TMSI allocation strategy, and supporting apparatuses, that are suitable for use with communication systems that employ the “in pool” concept.
There is also a need for strategies, and supporting apparatuses, for determining what step size(s) to use for a given system.